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ABSTRACT 


As  many  organizations  transit  through  Nolan's  phases  of 
ADP  evolution,,  the  process  of  designing  systems  to  satisfy 
their  data  needs  has  become  extremely  complex.   Application- 
oriented  design  techniques  have  given  way  to  data-oriented 
concepts  such  as  Jn-f  ormat  i  on  Engineering.   One  of  the 
primary  tools  of  Information  Engineering  is  the  group  of 
management  -functions  known  as  Data  Administration.   Naval 
Supply  Systems  Command  (NAV'SUP)  has  established  a  data 
ad m i  n i  s t r a t  i  on  branch  in  a. n  a 1 1 emp t  t o  i  n t eg r a t e  t hr ee 
logistic  information  systems;;  SUADPS  REAL-TINE,  UADPS-SP  and 
UICP, 
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I.    INTRODUCTION 

Through  the  years,  the  design,  implementation,  and 
maintenance  of  computer  information  systems  has  become  one 
of  the  most  important  elements  of  an  effective  organisation. 
An  army-  is  commonly  referred  to  as  "marching  c:<n    its 
stomach".   An  organization  marches  not  only  on  the  content 
of  its  information,  but  also  on  how  it  accesses  that 
information  up  and  down  its  organizational  structure. 

Many  organizations  are    evolving  towards  Richard  Nolan's 
concept  of  "mature"  data  processing  users  CRef.  13. 
Computers  are    no  longer  used  just  to  assist  the  operational 
managers  in  the  day  to  day  transactional  processing  as  they 
were  five  to  seven  years  ago.   Managers  at  all  levels  oi     the 
organization  need  information  to  make  countless  decisions. 
Today's  c  o  m p u  t  e  r  t  e c  h  n o 1 o g  y  p r o v  i d e  s  the  c  a p a  b  i 1 i t  y  fc o 
retrieve  needed  infor m a. t  ion  f  r o m  t h r o u g h ou t  t h e 
organization.   However.,  the  weak  link  is  the  compatibility 
of  data  and  data  structures  to  allow  access  to  the 
i  nf or mat l on  of  the  organ i z at i on . 

Much  attention  has  been  given  to  the  development  and 
i  improvements  in  computer  hardware.   These  improvements  have 
been  easy  to  observe.   Early  computers  that  contained  small 
amounts  of  memory  were  physically  huge  and  required  large 
investments  of  capital.   Management  concern  was  with  keeping 


the  computer  busy  by  processing  millions  of  transactions 
that  were  relatively  easy  to  program.   Today,  processors 
which  possess  almost  a  million  bytes  of  computer  memory  are 
commonplace  on  workers"  desks  throughout  the  organization. 
Computers  have  become  smaller,  cheaper,  faster,  more 
reliable,  and  easier  to  maintain  than  earlier  models.   Now 
management  concern  is  with  coordinating  all  the  computer 
systems  in  an  organization  in  order  to  support  and  control 
an  effective  overall  information  system. 

The  Naval  Supply  Systems  Command  (NAVSUP)  is  similar  to 
any  large  organization  with  computer  information  systems. 
In  the  mid  1960's,  NAVSUP  developed  three  major  financial 
and  inventory  control  systems  to  provide  support  for  its  tri 
level  organization.  They  are    the  Shipboard  Uniform  Automated 
Data  Processing  System  (SUADPS) ,  the  Uniform  Automated  Data 
Processing  System  for  Stock  Points  (UADPS-SP) ,  and  the 
Uniform  Inventory  Control  Point  sytem  (UICP) .   These  systems 
were  d & s i  g n e d  u sing  second  g e n e r  a 1 1 o n  ha r d w a r  e  a n d  s o f  t  w a r  e 
t  echn  i  g u e s  w i  t  h  m a  j  or    e m p h  a s i  s  o n  i  n  d  i.  v  i  d u a  I.  f  i  1  e 
p roc ess i  ng . 

Today,  all  three  of  these  major  systems  are  being 
redesigned  to  utilize  the  state  of  the  art  hardware 
technology.   N  A  V  S  U P  h a  s  t h  e  u n i  g u  e  o p p o r  t  u n i t y  t o  d  e  s  i  q  n 
these  s  y  s  t  e  m  s  t  o  p  r  o  v  i  d  e  i  n  t  e  g  r  a  t  i  o  n  t  h  r  o  u  g  h  o  u  t  t  h  e 
organization  and  to  take  an  important  step  towards  realizing 
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a  true  corporate  information  system  allowing  top  management 
access  to  the  information  that  they  need. 

This  thesis  will  discuss  the  problems  of  coordinating 
the  design  of  the  three  systems  experienced  by  NAVSUP  with 
an  emphasis  on  the  role  of  data  administration  in  the 
overall  concept  of  information  systems.   Much  attention  will 
be  given  to  the  concepts  of  software  design  including  the 
basics  of  Information  Engineering  which  is  being  used  by  the 
Fleet  Material  Support  Office  (FMSO) ,  the  central  design 
activity  for  UADPS-SP  and  UICP.   After  the  discussion  of  the 
three  replacement  systems,  the  need  for  a  strong  data 
administration  activity  at  NAVSUP  Headquarters  to  allow  for 
vertical  integration  will  be  emphasized. 


II.  BACKGROUND 

A.   NAVSUP  ORGANIZATION 

NAVSUP  supports  logistic:  operations  through  a    tri  --level 
organizational  structure  as  shown  in  Figure  1,   The  bottom 
layer  is  the  ship  or  squadron  supply  department  which 
maintains  an  inventory  of  up  to  100,000  line  items  for 
issue.   If  a  needed  part  is  not  available,  a  referral  is 
sent  to  the  next  level,  the  nearest  stock  point  (Naval 
Supply  Center  or    Depot).   A  stock  point  carries  an  inventory 
of  between  90,000  and  1,500,000  items  and  satisfies 
approximately  757.  of  the  referral  requests  it  receives.   The 
unfilled  referrals  are    sent  to  either  the  Aviation  Supply- 
Office  (AS0)  or  the  Ship  Parts  Control  Center  (SPCC),  the 
third  level  in  the  logistic  chain.   AS0  and  SPCC  do  not 
stock  any  parts  for  issue.   They  function  as  inventory 
control  p  o  i  n  t  s  ( I C  P  s )  a  net  m  o  n  i  fc  o  r  t  h  e  wo  r  1  d  w  i  d  e  i  n  v  e  n  t  o  r  y  •::•  f 
supply  parts,  the  status  of  depot  level  repai rabies,  and  the 
contracts  for  new  procurements,.   The  two  ICP's  handle  o-/<^r 
2,000,000  demands  every  month,,   The  TCP  will  direct  the 
issue  of  a  needed  part  from  any  supply  source  throughout  the 
wor 1 d . 
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Figure  1  — Logistic  Support  Organisation 

Each  level  in  the  supply  chain  utilizes  a  different 
sophisticated  automated  inventory  control  system.   These 
computer  systems  were  effective  in  the  past  in  assisting  the 
NAVSUP  activities  in  performing  their  missions.   However , 
for  the  last  ten  years,  the  pace  of  operations  and  the  sheer 
size  of  the  computing  .load  have  created  a  desperate  need  for 
modern  information  systems  at  all  levels.   Additionally, 
NAVSUP  headquarters  now  needs  access  to  information  at  all 
three  I e v  e 1 s  m u  c  h  f  a s  t  e  r  t h a  n  w h  a t  1 s  c  u  r  r  en 1 1 y  a  /  a i 1  a b 1 e  * 
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The  Navy's  information  needs  have  changed  dramatically 
since  the  earlier  systems  were  developed.   They  were 
designed  as  report  generators  executing  in  batch  mode  to 
provide  page  upon  page  of  output,  needed  by  inventory  control 
clerks.   This  satisfied  the  operational  level  of  management 
information  needs.   Upper  and  middle  management  do  not 
recei ve ^suf f i ci ent  information  from  these  systems  to  answer 
the  "what  should  we  be  doing?"  and  "what  is  our  status  right 
now?"  type  questions.   For  NAVSUP,  the  need  for  integrated 
information  systems  was  made  obvious  during  1979  and  1980 
when  naval  units  were  required  to  operate  in  the  Indian 
Ocean  for  extended  periods  outside  their  normal  logistics 
chain.   Top  management  had  difficulty  in  getting  up  to  date 
information  from  the  ships,  stock  points,  and  ICPs  to  make 
the  many  decisions  to  adequately  support  ail  units.   The 
lack  of  integration  among  the  three  major  information 
systems  has  become  a  chief  concern  of  the  Inventory  and 
Information  Systems  Directorate  (SUP— 04)  at  NAVSUP 
H  e  a  d  q u  a r  ters „ 

0.   INFORMATION  SYSTEMS 

An  information  system,  in  general,  consists  of  hardware, 
software,  data,  personnel,  and  procedures.   Each    element 
must  interact  correctly  in  order  to  have  an  efficient  and 
effective  system.   With  the  remarkable  advances  in  the-? 
a m o u  n  t  o  f  comp  u  ter  m e m o ry  a  v  a  i  1  a  b  1  e ,  t  h  e  p  i.  v o t  a  1  e  1  e m ent  h  a  s 


shifted  from  the  computer  processor  itself  to  the  data 
contained  within  a  system.   Data  is  now  viewed  as  a  valuable 
resource  to  be  shared  throughout  the  system.   The  user  must 
become  more  responsible  for  the  integrity  of  the  data  than 
was  required  by  the  older  systems.   This  concept  requires  a 
coordinated  effort  by  the  designers,  managers,  and  users  to 
ensure  new  information  systems  will  satisfy  the  requirements 
of  individual  activities  and  allow  access  to  and  from  other 
information  systems.   This  need  for  integration  has  led  to 
the  development  of  a  new  methodolgy  for  systems  design  known 
as  information  engineering. 

Until  recently,  NAVSUP  activities  at  each  level  were 
allowed  to  develop  information  systems  to  satisfy  their  own 
requirements  with  little  concern  for  interfacing  with  other 
systems.   This  "isolated"  design  methodology  evolved 
primarily  because  each  activity's  data  processing 
requirements  centered  around  specific  functional  programs 
such  as  pa y r oil,  p e r s o n n e 1  a ceo u n t i  n g ,  o r  i n v ento r y 
management,   Such  programs  were  developed  using  second 
generation  computers  and  were  designed  for  independent  file 
processing.   During  this  period,  the  Navy  implemented  three 
large  automated  logistics  systems  to  handle  uniform  data 
processing  requirements:   UICP  (with  UNIVAC  hardware'  for 
t he  two  in v e n t o r y  c o n t r o 1  p o i n t s ,  U A D P B - S P  ( w i  t h  B u r r o u g h s 
e g u  i  p m e n  t  a n d  f  i  1  e  s t  r  u c  t.  u res)  for  s t  o c  k  p o  i  n  t  s ,  an d  S U A D P S 
(with  UN I VAC  hardware)  for  large  fleet  units.   The  lack  of 


compatibility  among  these  systems  forced  NAVSUP  to  support 
many  redundant  applications  and  data  tiles.   Because  of  the 
size  of  these  computer  systems,  the  immense  investment  in 
maintaining  and  expanding  them  through  the  years,  and  a  long 
period  o-f  ADP  -funding  short-falls,  the  Navy  was  prohibited 
-from  replacing  its  outdated  equipment  and  processes  even 
though  newer  hardware  and  more  efficient  applications 
ex i  sted. 

C.   NAV'SUP  MODERNIZATION  PROGRAMS 
I. .  Qvervi  ew 

NAVSUP  is  now  involved  with  modernizing  its  three 
major  information  systems  to  catch  up  with  the  technological 
advances  of  the  past  twenty  years  and  allow  managers  at 
every  level  to  have  access  to  the  information  they  n^sd . 
The  programs  ar&    :     UICP  RES Y STEM I Z  AT  I  ON,  LI  ADP  S  Stock  Point 
ADP  Replacement  (SPAR),  and  SUADPS  Real-Time,   The  first  two 
systems  are    being  designed  by  FMSO  in  Mechani csburg, 
P e n n s y  3.  v  am  a  u sing  man y  o f  t  h e  tec h n  i  q u e s  o  f  i  n  f  o r  m a 1 1  o n 
engineering,   SUADPS  Real-Time  is  under  the  cognizance  of 
Navy  Management  Systems  Support  Office  (NAVMASSO) ,  Norfolk, 
Virginia.   It  is  a  much  smaller  system  and  has  kept  many  of 
the  traditional  file  design  techniques.   Figure  2  summarizes 
the  key  elements  of  the  three  projects. 
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2.   SUADPS  Real-Time 

SUADPS  Real-Time  is  a  user  oriented  on-line 
interactive  supply  and  -financial  system  which  utilizes  the 
SNAP  I  computer  hardware  to  support  designated  shipboard. 
Marine  Air  Group  (MAG)  Supply  Departments,  and  certain  Shore 
Intermediate  Maintenance  Activities  (SIMA)  mission  support 
functions,   It  makes  maximum  use  of  the  interactive 
capabilities  of  the  hardware  in  data  input,  data  update,  and 
data  base  query  operations.   It  replaces  the  original 
version  of  SUADPS  which  was  a  card  oriented  batch  system 
designed  for  the  UN I  VAC  1500  system. 

The  primary  reason  for  the  development  of  SUADPS 
Real-Time  is  to  take  advantage  of  the  upgrade  in  computer 
processing  capability  made  possible  by  the  Shipboard  Non 
Tactical  ADP  Program  for  large  ships  (SNAP  I).   SNAP  I 
removed  the  second  generation  U1500  systems  from  the  field 
activities  and  replaced  them  with  a  fourth  generation  mini 
computer,  the  Honeywell  DPS -6.  The  DPS -6  increases  the 
memory  capability  from  16,000  to  2,000,000  bytes  and  provides 
for  on-line  storage  of  at  least  12,000,000  bytes.   With  this 
quantum  leap  in  computer  capacity,  the  capability  for 
creating  a  more  effective  system  became  a  reality.   SUADPS 
Real-Time  is  one  of  several  on-line  systems  being 
implemented  on  the  SNAP  I  systems,   According  to  its  charter 
LRef.  23,  it  is  designed  to  a 
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a.  Reduce  the  time  and  effort  required  to  process 
supply  transactions  and  to  access  supply 

i  nf ormat ion. 

b.  Improve  supply  response  times  tor  organisational  and 
intermediate  level  material  requirements. 

c.  Improve  utilization  of  fleet  operations  and 
maintenance  funds. 

d.  Improve  accuracy,  consistency',  and  timeliness  of 
supply,  financial,  and  logistics  data. 

e.  Provide  a  direct  interface  with  maintenance  systems. 


An  important  element  missing  from  this  design 
criteria  is  the  need  to  interface  with  UADPS-SP  or  UICP, 
NAVMASSQ  chose  to  continue  many  of  the  file  design 
techniques  of  the  old  BUADPS  system  to  allow  easier 
transition  to  the  new  system  and  interface  with  the  ship's 
3M  maintenance  reporting  system.   This  has  resulted  in  data 
redundancy  and  lack  of  file  integration.   Many  processes  a.rB 
duplicated  for  one  transaction.   Using  a  data  base 
management  system  (DBMS)  would  have  reduced  the  redundacy 
and  possibly  allowed  better  interaction  with  external 
systems.   Keeping  the  imbedded  file  structures  has  also  made 
the  future  development  of  a  NAVSUP  corporate  data  base  much 
more  difficult.   Other  factors  such  as  getting  a  system  out 
to  the  fleet  as  soon  as  possible  to  use  the  new  hardware 
I:  o  o  k  precedence. 

M  A  V  li  A  S  S  0 '  s  i  m  p  I  e  i  n  e  n  t  a  1 1  o  n  p  Ian  1  n  vol  v  e  s  p  h  a  s  i  n  g  1  n 
versions  of  the  new  £5  U  AD  PS  RT  as  they  are    developed  and 
b  a  c  k  f  i  1 1  i  n  g  p  r  e  v  i  o  u  s  I  y  1  n  s  t  a  3.  3.  e  d  s  y  s  t  e  m  s .   U  n  f  o  r  t  u  n  a  t  e  1  y , 


users  are  discovering  many  bugs  in  the  system.   This 
decreases  their  -faith  in  the  system  and  increases  their 
reluctance  to  change  from  many  outdated  processing  methods 
such  as  using  punched  card  input.   Currently,  USS  Dixon 
(AS— 37)  homported  in  San  Diego  has  the  latest  version  of 
SUADPS  Real-Time  on  the  west  coast.   Due  to  the  phase-in 
approach,  stock  control  personnel  ar&    -forced  to  perform  dual 
processing  until  final  system  development  is  completed  in 
approximately  two  years.   The  dual  processing  involves 
entering  data  into  the  "real  time"  -files  -for  query 
processing  and  requisitioning  material,  then  downloading 
that  data  for  processing  to  the  "official "  data  files  for 
processing  by  the  old  SUADPS  system  running  in  emulation 
mode.   While  the  old  system  is  running,  the  ship  loses  its 
"real  time"  capabilities.   Additionally,  regui sit  ions  which 
must  be  passed  off -ship  3.r&    being  prepared  and  submitted  in 
three  different  methods  which  vary  from  ship  to  ship 
depending  on  their  exper 1 ence*   Requisition  processing  is 
accomplished  by  (1)  direct  input  into  a  Burroughs  terminal 
and  utilising  a  fleet  on-line  program,   (2)  submitting  a 
SUADPS  tape  to  the  stock  point  for  UADPS  processing,  or     (3) 
writing  ou t  a  requisition  d oc u men  t  a n d  h  a v i n q  t  h e  s t  oc  k 
point  prepare  the  automated  requisition  card. 

S  U  A  E'  P  S  Real  —  T  i  m  e  h  a  s  c  r  e  a.  t  e  d  a  n  e  w  element  in  the 
shipboard  supply  department  operations  by  giving  remote 
access  to  its  supply  files.   Under  the  old  SUADPS 
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processing,  one  or  two  storekeepers  and  the  stock  control 
officer  were  SUADPS  trained.   They  were  responsible  for 
ensuring",  that  supply  documents  were  correctly  prepared  -for 
submission  to  the  data  processing  division.   After  the 
inventory  programs  were  executed,  they  then  had  to  work- 
error  listings  of  improper  transactions.   It  was  not 
uncommon  for  a  single  transaction  to  require  two  weeks  of 
processing  be-fore  being  completed  if  it  was  originally 
submitted  incorrectly.   In  the  meantime,  the  rest  of  the 
supply  department  was  working  with  printouts  of  the 
inventory  files  that  were  up  to  two  weeks  old.   With  SUADPS 
Real-Time,  all  storekeepers  will  be  involved  with  the 
inventory  data.   Remote  terminals  at  stock  control  and  most 
of  the  storerooms  will  allow  direct  on-line  processing  of 
receipts,  issues,  and  requisitions.   This  will  require 
SUADPS  training  for  all  supply  personnel  to  ensure  data, 
i ntegr i t  y , 

The  new  system  allows  output  of  requisition  *:  i  I  es  to 
either  floppy  disk,  magnetic  tape,  or    punched  cards, 
Currently,  the  stock  points  ar&    only  capable  of  using  tape 
or    punched  cards.   Because  of  initial  problems  with  the 
UADPS-SP  system  reading  the  Honeywell  tapes,  the  majority  of 
ships  with  SUADPS  Real-Time  -3.r^    reluctant  to  change  to  the 
new  technology  and  B.r^    continuing  to  use  the  punched  card 
output  that  they  used  for  twenty  years.   This  severely  slows 
processing  time.   This  will  continue  to  be  a  problem  until 
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the  "second  generation  mentality"  is  removed  through 
training  and  hope-Fully  with  the  implementation  of  the  SPAR 
equipment  at  the  stock  points  which  is  being  designed  to 
allow  direct  transfer  of  regui sit  ions  by  floppy  disks. 

3.   Stock  F'oint  ADP  Replacement  Project 

The  Stock  Point  ADP  Replacement  Project  (SPAR) 
received  its  charter  from  NAVSUP  in  March  19S3.   It  has  two 
main  objectives:  (1)  replace  the  computer  systems  at  25 
major  data  processing  facilities  that  provide  services  to  72 
activities  which  utilise  the  Uniform  Automated  Data 
Processing  System  for  Stock  Points  (UADPS— SP> ;  (2)  the 
modernization  of  UADPS— SP  to  improve  the  level  of  supply 
support  provided  to  the  operating  forces  of    the  Navy, 
Deployment  of  new  hardware  and  software  will  extend  into  the 
1990' s  with  a  contract  life  of  24  years  to  allow  tor 
technological  improvements  and  capacity  expansion  as 
required.  CRef  .  31 

Stock  point  computer  systems  have  been  operating  at 
full  capacity  for  years.   Because  of  the  sheer  size  of  SPAR 
and  the  lead  time  for  system  acquisition  and  development, 
the  Navy  implemented  the  Navy  Stock  Point  Logistic 
Integrated  Communication  Environment  (SPLICE)  as  an  interim 
program.   The  primary  objectives  of  SPLICE  ^r<^    to  relieve 
the  saturation  of  computer  systems  currently  at  the  stock 
p  o  i  n  t  s  a  n  d  t  o  p  r  o  v  i  d  e  for  the  t  e  1  e  c  o  m  m  u  n  i  c  a  1 1  on  n  ej  e  d  s  o  f  the 
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modernized  UADPS.   SPLICE  was  envisioned  as  a  quick  stop-gap 
measure  to  allow  -for  a  controlled  redesign  effort  in  SPAR. 
However ,'.  problems  with  the  establishment  of  network  protocol 
for  the  Department  of  Defense  Network  (DDN)  has  delayed  the 
actual  implementation  of  SPLICE,   Meanwhile,  the  design 
phase  of  SPAR  has  pushed  forward. 

The  SPAR  project  involves  replacing  60  medium  scale 
computers  and  converting  or    redesigning  7800  programs  that 
contain  11.5  million  lines  of  source  code.   It  does  not 
include  the  redesign  or    conversion  of  the  hundreds  of  local 
programs  that  exist  throughout  the  system.    The  completed 
system  is  being  designed  to  efficiently  interface  with  both 
the  UICP  and  SUADPS  Real  Time  systems.   Since  it  is  such  a 
huge  project.-,  a  "risk  aversion"  attitude  has  partitioned  it 
into  three  main  phases:   (1)  hardware  acquisition  with 
equipment  selection  now  scheduled  for  March  1987,  (2) 
conversion  of  the  current  UADPS  system  to  execute  on  the  new 
hardware,  and  (3)  modernisation  of  UADPS.   Each  phase  has  a 
separate  manager  at  NA'v'SUP  headquarters. 

The  transistion  plan  for  the  replacement  project 
discussed  four  different  alternatives  for  replacing  the 
current  software  including  standard  conversion,  generic 
COBOL,  shell  or  bridges,  and  redesign.   An  initial  decision 
t o  i m p 1 e m e n t  S P A R  with  c o n v e r t e d  soft w a r e  v ice  a  m odernized 
system  was  made  because  many  of  the  design  techniques  that 
the  modernization  team  will  use  B.r^    a  radical  departure  from 


traditional  methods.  The  cost  o-f  having  the  system  fail 
during  implementation  at  any  stock  point  is  deemed  too  high 
to  risk.  Also,  the  feeling  is  that  conversion  will  be  the 
quickest  method  to  get  the  new  hardware  to  the  activities. 
A  final  decision  will  be  made  in  late  1985  after  the 
redesign  team  at  FMSQ  prepares  its  initial  package.  LRef  41 
The  SPAR  redesign  team  at  FMSO  began  its  project  by 
preparing  a  functional  description  of  all  the  tasks 
performed  by  the  current  version  of  UADPS-SP.   Utilizing  a 
fourth  generation  software  design  tool,  DATA  DESIGNER,  they 
compiled  the  logical  relationship  of  all  the  functions  and 
the  data  files  with  which  they  interact.   This  identified 
data  classes  with  one  to  one,  one  to  many,  and  many  to  many- 
relationships.   The  team  took  this  output  to  the  users  and 
asked  "Is  this  really  the  way  you  do  your  processing"^"   At 
the  same  time,  they  queried  the  users  on  what  they  thought 
the  new  system  should  do.   This  bottom-up  design  method 
contradicts  one  of  the  key  elements  of  Information 
Engineering  (IE).   In  IE,  top  management  decides  what  the 
new  system  should  do  and  lets  the  design  work  top-down  in 
the  conceptual  stage.   However,  IE  also  assumes  that 
corporate  headquarters  has  a  firm  description  of  its 
information  needs  included  in  its  strategic  plan.-   The 
pressures  of  time  forced  FMSO  to  query  the  users  *:irst,  make 
managerial  recommendations,  and  forward  its  intentions  to 
N  A'v'SUP  He  a  d  q  u  a  r  t  er  s  , 
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From  the  preliminary  results,  the  FMSG  team  has 
decided  to  proceed  with  a  phased  implementation  of  the 
redesigned  software  and  backfit  organisations  with  the  new 
software  as  it  is  developed  instead  of  attempting  to 
prototype  all  of  the  changes  on  one  system.   This  is 
si  mi  liar,  to  the  SUADPS  REAL-TIME  implementation  plan.   The 
major  difference  is  that  under  SPAR  there  will  be  no 
duplicate  processing  under  emulation  mode.   Currently,  the 
redesign  team  is  continuing  its  development  work  while 
serving  as  a  beta  test  site  for  a  new  fourth  generation 
software  design  program. 

4.   LI  I  UP  RESYSTEMIZATION 

FMSO  has  also  been  tasked  with  designing  the 
mod er niz ed  sof t war e  f or    the  i n ven t or y  c on t r o 1  point  (I CP ) 
level.   UICP  RESYSTEMIZATION  or  RE30LICI TAT  I  ON  is  the  ICP 
version  of  SPAR.   Uniform  Inventory  Control  Point  (UICP)  is 
a  collection  of  programs  very  similar  to  the  UADPS-SP 
system.   The  current  system  involves  IBM  hardware  at  two 
sites,  SPCC  in  Mechani csburg ,  Pennsylvania  and  ASO  in 
Philadelphia,  Pennsylvania.   RESYSTEMIZATION  efforts  began 
in  1978  with  an  expected  completion  date  of  March  1989.   The 
p  r  o  j  e  c  t  h  a  s  a  1  r  e  a  d  y  selected  and  ins  t  a  lied  I B  M  30  8  0  /  309  0 
hardware. 

The  software  redesign  effort  began  before  the 
d  e  v  e  1  o p  m en  t  o  f  t  hi  e  d  e  s  i  g  n  t  e c  h  n  i  q  u  e  s  o  f  I  n  f  o r  m  a  t  i  o  n 


Engineering.   However,  the  redesign  team  has  been  in  close 
communication  with  the  SPAR  team  and  would  like  to  integrate 
many  of  the  concepts  o-f  IE  into  their  project.   This  may 
prove  to  be  very  difficult  due  to  the  mechanics  involved. 
Currently,  the  project  is  also  geared  towards  a  phased 
implementation  with  the  -financial  accounting  subsystem  being 
the  -first  scheduled  to  come  on  line.   The  system  is  built 
around  the  IBM  IDMS  data  base  system  which  could  be  a 
problem  -for  integration  of  UADPS-SP  AND  UICP  data.   The 
inter-face  between  SPAR  and  UICP  is  deemed  critical  to  the 
-future  development  of  a  corporate  data  base  capability. 
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III.  SOFTWARE  DEVELOPMENT/ INFORMATION  ENGINEERING 

A.   BACKGROUND 

To  the  layman,  the  quantum  leap  in  computer  technology 
during  the  past  five  to  seven  years  has  been,  at  best,  mind 
boggling.   Much  attention  has  been  given  to  the  development 
and  improvements  in  hardware  which  have  been  easy  to 
observe.   Early  computers  that  contained  small  amounts  of 
memory  were  physically  huge  and  required  a  large  investment 
of  capital.   Today,  processors  which  work  with  al  roost  a 
million  bytes  of  memory  ar^    commonplace  on  workers'  desks  in 
a  1  m o s t  e v e  r  v  o -f  f  i  c e  b u i  1  d i  n g  .   E v en  a s  t  h e y  h a  v e  b e c o m e 
smaller,  computers  ar&    cheaper,  faster,  more  reliable,  and 
easier  to  maintain  than  earlier  models. 

Unseen  to  most  people,  a  remarkable  change  in  the  manner 
in  which  computers  ar&    programmed  has  been  taking  place. 
D  u ring  t h e  e  a  r 1 y  d a  y  s  o f  c  o  m p  u  t  e r  p  t '  o g  r  a m m i n g  *  t h  e 
development  of  software  was  severely  limited  by  the 
capabilities  of  the  computer.   As  the  computer  became  less 
r estr  i  c  1 1  v e ,  t he  p r  o g r  a m s  b e c a m e  m o r e  c o m p  1  e v.    b e c a u s e  m a n 
demanded  more  -from  this  electronic  resource.   However,  until 
recently,  the  manner  in  w h i c h  p e o p 1 e  a p p r o a c h e d  t h e 
programming  problem  remained  the  same.   Most,  software  was 
developed  top —down  and  was  application  or     function  oriented. 
But  a%  demand  rcr    solutions  to  more  o^-n>-r.^i.  problems 
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increased,  the  methodology  of  programming  has  slowly  evolved 
into  an  "information  engineering"  project.   To  appreciate 
the  power  and  complexity  of  information  engineering,  a  brief 
description  of  the  earlier  methods  is  needed. 

B.   ERAS  OF  SOFTWARE  DEVELOPMENT 

The  evolution  of  computer  systems  and  software 
development  has  been  characterized  by  three  eras  ERef.  5  3. 
In  the  first  &ra,     programming  was  initially  accomplished  by 
hardwiring  the  computer,   Each  different  application  being 
executed  on  the  computer  required  a  complete  rewiring  of  the 
computer,   The  programmers  were,  in  fact,  electrical 
engineers.   Once  the  second  generation  computers  were 
developed,  non-engineers  became  involved.   The  use  of 
compilers  and  higher  level  programming  languages  gave 
proa  rammers  much  more  flexibility.   But  for  a.  period  of 
twenty-five  -/ears,  all  programs  were  developed  to  solve  a 
specific  p r o I ::<  1  e m .   M u ch  redun d a n c y  i  n  fc h e  p r o g r  a m m i  n g  e f  f  o r  t 
existed.   Also,  there  were  many  ways  to  approach  the  same 
problem,   P r o g  r  a mm e r  s  u  sed  different  t  e c  h n i g u e s  a n d 
a.  1  g  o  r  i  t  h  m  s  a  n  d  m  o  s  t  p  r  o  g  r  a  m  s  h  a  d  v  e  r  y  1  i  m  i  t  e  d  d  i  s  t  r  i  b  u  1 1  o  n  -- 

The  second  ers.    reflected  a.  significant  leap  in  the 
capabilities  and  functions  of  computer  systems™   Systems 
were  now  being  used  by  more  than  one  person  or    organisation 
so  programs  had  to  be  more  flexible.   Product  software 
evolved  which  required  months  or  <>?zrB    of  designing,  coding, 


testing,  and  evaluating  be-fore  being  used.   Libraries  of 
common  programs  became  necessary.   However  most  software 
development  still  was  application  oriented,  and  the 
applications  were  becoming  more  and  more  complex.   The  cost 
of  software  d e v e 1 o p m e n t  a n d  m a i  n t  e n  a n c e  began  t  o  s k y  r  o c  k e  t , 
and  soon  exceeded  hardware  costs,   During  this  "growth" 
stage  o£  data  processing  development,  a  better  method  of 
programming  had  to  be  found  to  control  the  escalating  costs. 
Data  processing  experts  such  as  C.F.  Gibson  and  Richard 
Nolan  voiced  their  concern  over    the  uncontrollable  growth  in 
data  processing  requirements  and  tried  to  provide  industry 
with  guidelines  towards  a  "mature"  DP  environment  CRef.  6  1. 
Many  of  their  concerns  became  real  as  computer  processing 
m o v e d  i  n  t o  t  he  t  h  i  r  d  era  . 

The  third  era.    of  software  development  began  with  the 
arrival  of  microprocessors  and  distributed  computing  systems 
a  n  ci  c  on  tin  u  e  s  to  d  a  y .   The  need  f  o  r  software  g  r  e  a  1 1  y  e  '■■■  c  e  e  d  s 
t  he  p e r  s o n n e  1  a n d  1: e c h n  i  c a  1  re s o u r  c e s  a v a i  1  a b  1  e »   T h e  f  a c  t 
that  many  functions  -3. re    now  hardwired  into  the  processors 
h  e  1  p  s  „  ta  u  t  t  h  e  c  o  m  p  u  t  i  n  g  w  o  r  1  d  c  a  n  n  o  1  on  g  e  r  a  t  f  o  r  d  t  h  e 
1  u >{  u r  y  of  putting  m o n  the  o r  y e a r  s  i  n  t  o  d e v eloping  a  p r  o q r  a m 
that  does  not  s a t  i  s f  y  c urre n t.  req u i  r e m e n  t  s .   !i a n v  b u s i  n e s s e s 
■3. re    discovering  how  important  the  computer  can  be  to  both 
their  day-"t  o—  d  ay  '"Derations  and  t.o    ths  \  r  long  ranoe  planning 
efforts,.   However,  marry'  users  are    frustrated  with  the 
t  r  a  d  i  t  i  o  n  a  1  p  r  c  :<  q  r  s.  m  m  i  r i  g  r  e  q  u  i  r  e  m  e  n  t  s  and  1 1  m  i  t  a  t  i  o  n  s , 


Charles  Rubin  states  "Ideally,  what's  needed  is  software 
with  a  -flexible  command  processor  that  would  let  the  user 
de-fine  .  .  .  the  way  the  user  likes  to  communicate  ,  .  .  The 
sol  u t i on  is  he y o n d  o u r  c u r r e n t  m e a n s ,  a  1 1 h o u g h  t h e r e  a r e 
some  integrated  packages  on  the  horizon  that  promise 
'modeless'  operation  „  .  »  .  CRe-f.  7.1   This  "need"  requires 
a  new  method  of  programming.   A  major  step  in  satisfying 
that  requirement  is  the  emergence  of  software  engineering. 

C.   SOFTWARE  ENGINEERING 

Previous  programming  techniques  centered  on  a  flowchart 
approach  that  was  concerned  with  procedural  or  "how  to" 
questions.   Software  engineering  is  geared  towards  a  "what 
to  do"  question  and  is  functionally  oriented.   To  ensure 
efficiency  and  effectiveness  of  the  software  product,  a 
great  deal  o f  p 1  a n n i n g  is  re q u i r e d .   H e n c e ,  t h e  e n gineering 
attitude  is  employed.   It  is  a  methodology  that  uses 
t  e c h n  i  q u e s  t  h a  t  s.r  e  a p p  I.  i  c  a  1 1  c :< n  i  n  d e p e n d e n  t ,    1 1  i  s  m o del  e d 
o n  t  h e  t  i  m e - p r o  v en  t  e c  h n i q u e s ,  m e  t  h o d s ,  a n d  c o n t  r  o 1 s 
associated  with  hardware  development  and  is  centered  on 
three  key  objectives:  (1)  a  well  defined  methodology  that 
addresses  a  software  life  cycle  of  planning,  development, 
and  maintenance,  (2)  an  established  set  of  sew ::tware 
components  that  documents  each  step  in  the  life  cycle  and 
shows  traceabi 1 i t y  from  step  to  step,  and  (3)  a  set  of 


predictable  milestones  that  can  be  reviewed  at  regular 
intervals  throughout  the  software  lite  cycle,  C  Ref.  SI 

The  three  phases  of  a  software  life  cycle  are    the  key 
elements" of  software  engineering,   The  planning  phase 
includes  software  planning,  software  requirements  analysis 
and  definition,  and  a  review  of    the  software  requirements 
s p e c  i  f  i  e a  t  i  o n „   F r  o m  t  he  specific  a  t  i  o n s  g e n e r  a t  e d  d  u r i n g  t  h e 
planning  phase,  deliverables  are    created  during  the 
development  phase,   This  phase  includes  two  software  design 
steps,  coding,  unit  testing,  integration  testing,  and 
v  a  1  i  d  a  t  i  o  n  t  e  s  t  i  n  g «   The  f  i  n  a  1  p  h  a  s  e  i  s  t  h  e  m  a.  i  n  t  e  n  a  n  c:  e 
phase  wh  ich  in  vo  Ives  ma  i  n  t  a  i  n  :i.  n  g  c  ode  or    mod  i  f  v  i  n  g  t  h  e 
software  to  ensure  its  reliability,  effectiveness,  and 
relevance.   Today,  40%  to  70 "A    of  a  company's  programming 
effort  is  involved  with  software  maintenance.  ERef  9  ']   The 
large  amount  of  maintenance  during  the  life  cycle  of  the 
software  is  often  overlooked  during  the  planning  phase  and 
r e s o u r c e s  a r e  n o t  a v  a  i 1  a b 1 e  w h en  need e d , 

Software  engineering  is  definitely  improving  the 
e  f f e  c  t  i  v  e n  ess  and  r  e 1 i a b i 1 i t y  o  f  m a  n  y  p  r o g  r  a  m m i  n g  p r o  j  e c  t s „ 
But  it  is  still  a  traditional  programming  methodology  in  the 
sense  that  large  teams  of    programmers  are    required  as  well 
as  considerable  time,.   This  does  not  solve  the  problem  of 
t  o  d  a  y ?  s  u  s  e  r  s  w  h  o  r  e  g  u  i  r  e  t  h  e  c  a  p  a.  b  i  1  i  t  y  t  o  3.  n  s  t  a  n  t  a.  n  e  o  u  s  1  y 
answer  scores  of  questions  regarding  a  wide  range  of  data, 
!  hey  cannot  afford  to  wait  *  or    a  programming  team  to  pros  id*-1 


them  with  a  software  tool.   Information  engineering 
represents  a  radical  change  in  program  design  that  will  in 
effect  take  the  responsibility  for  the  majority  of 
programming  away  from  the  application  programmer  and  place 
it  in  the  hands  of  the  user. 

D.    INFORMATION  ENGINEERING 

Information  Engineering  (IE)  is  a  discipline  that  is 
broader  than  software  engineering  arid  encompasses  all  the 
interrelated  disciplines  necessary  to  manage  an  effective 
data  center.   It  ties  the  design  of  the  data  center  squarely 
into  the  corporate  planning  processes  of  each  organization. 
A  mature  organization  lives  and  dies  on  its  data.   Contrary 
to  software  engineering  which  focuses  on  the  logic  used  in 
computerized  processes,  information  engineering  is  primarily- 
concerned  with  how  data  is  created,  updated,  and  used. 
Earlier  programming  methodologies  were  designed  around 
static  procedures.   IE  maintains  a    basic  premise  that  the 
type  of  data  used  in  an  enterprise  do  not  change 
significantly  while  procedures  using  the  data  will. 

1 .   Building  Blocks 

There  are    nine  basic  building  blocks  defined  for 
information  engineering  as  outlined  in  Figure  3.   Each  block 
is  dependent  on  the  firm  development  of  its  predecessors. 
T h e y  ar&i 


a.  Strategic  requirements  analysis 

b.  Information  analysis 

c.  Data  modeling 

d.  Procedure  formation 

e.  Data  use  analysis 

f .  D  i  s t  r  i  b  u t  i  on  ana 1 y  s  i  s 

g.  Physical  data  base  design 

h.  Program  specification  synthesis 

l,  Application  generation  without  programmers 

The  strategic  requirements  analysis  block  is  the  most 

important  and  the  most  overlooked  portion  of  IE.   In  this 

block,  the  overall  objectives  of  the  enterprise  and  the 

information  needed  to  accomplish  those  objectives  are 

determined.   Many  organizations  have  learned  the  hard  way 

about  the  wastefulness  of  appl i cat i on . software  created  to 

generate  paperwork  and  give  the  managers  little,  if  any, 

benefit.   Once  organizational  objectives  have  been 

determined,  the  second  block  performs  a  top-down  analysis  of 

the  types  of  data  that  must  be  kept  arid  how  they  relate  to 

one  another,   This  is  a  critical  process  because  the 

cornerstone  of  information  engineering  is  that  data 

structures  will  remain  stable.   During  the  third  step,  data 

m o d e 1 i nq,  a  d e t a i 1 e d  1 o g 1 c a 1  d a t a  b a s e  d e s i g n  i s  c r e a ted. 

The  key  is  that  the  data  is  structured  independent  of  how  it 

will  be  used.   The  f  o u r t h  b 1 o c k ,  p r o c e d u r e  f o r m a t  i o n , 

concerns  the  events  that  change  or  use  the  data  base,   These 

procedures  can  and  should  be  designed  and  programmed  by  the 

u  s  e  r  s .   T  o  e  n  a  b  1  e  n  on-  p  r  o  g  r  a  m  m  i  n  g  p  e  r  s  o  n  n  e  1  t  o  a  c  c:  o  m  p  1  i  s  h 

t  h  is,  i  n  f  o  r  m  a  t  :i.  o  n  en  q  i  n  e  e  r  i  n  g  i  s  s  t  r  o  n  q  1  y  d  e  p  e  n  d  e  n  t  u  p  o  n 

f  o  u  r  f  h  g  e  n  e  r  a  t  i  o  n  p  r  o  g  r  a  m  m  i  n  g  1  a  1 1  q  u  a  q  e  s  w  h  i  c  h  a  r  e  b  a  s  i.  c  a  1  1  y 


non-procedural  and  allow  coding  in  Englishlike  statements. 
Additionally,  there  is  the  capability  -for  automatic  code 
generation  using  the  procedure  charts  created  during  this 
b 1 oc  k . 

The  fifth  and  sixth  blocks,  data  use  analysis  and 
distribution  analysis,  prepare  the  data  organization  for  the 
physical:  data  base  design  step  of  block  seven.   In  earlier 
methodologies,  the  physical  structure  of  the  data  was 
dictated  by  the  application  being  programmed.   Block  eight, 
program  specification  synthesis,  integrates  the  different 
procedures,  documents  any  data  changes,  and  creates 
functionally  cohesive  program  code,   Finally,  block  nine 
represents  the  capability  of  application  development  without 
programmers  in  the  sense  of  dedicated  programmers  working  as 
a  team.   In  this  block  non-procedural  languages  allow  the 
user  to  answer  queries  on  the  data  base,  mode?],  "what  if" 
questions,  streamline  reports,  and  generally  get  to  the  data 
they  need.   Non-procedural  languages  differ  from  procedural 
languages  in  the  sense  that  a  procedural  language  specifies 
how  something  is  accomplished.   A  n  on  -  p  r  o  c  e  c.i  u  r  a  !.  1  a  n  g  u  a  g  e 
specifies  what  is  accomplished  but  not  how  in  detail,, 
Application  development  without  programmers  is  probably  the 
most  important  and  exciting  element  of  IE.   The  vast  backlog 
i  n  a p  p  1 1  c  a.  t  i  on  d  e  v e  1  o p  m e n  t  i  n  m o s  t  org  a n  i :z  a  t  i  o n  s  h  a s 
severely  restricted  the  flow  of  information. 
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By  using  all  of  the  above  blocks,  corporations  can 
develop  -flexible  systems  which  meet  overall  organizational 
information  needs  much  more  rapidly  than  bv  using 
traditional  design  methods  and  at  an  overall  lower  cost. 
CRef.  10.1 


2 »   L. i  fe  Cycle  Stages 

Software  engineering  assumes  a  life  cycle  of  three 
distinct  phases:   planning,  development,  and  maintenance. 
Information  engineering  decomposes  the  life  cycle  into  eight 
stages:   (1)  Business  strategy  planning,  (2)  Information 
strategy  planning,  (3)  Business  area  analysis,  (4)  Business 
system  design,  (5)  Technical  design,  (6)  Construction,  <7) 
T  r  a  n  s  i  t  i  o n  ,  a  n  d  <  8 )  P  r  o d  u  c  t  i  o n  .   E  a  c  h  of  t  h  e s e  s  t  a  g  e  s  h  a  s  a 
building  block  that  addresses  its  main  functions,   A  key 
element  is  the  existence  of  a  data  dictionary  or 
encyclopedia  that  is  referenced  during  each  one  of  the  life 
cycle  stages.   Without  a  good  da!: a  dictionary,  information 
e n g i n e e r i n g  w o u Id  be  i m possible. 
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Figure  3  -  Steps  in  Information  Engineering  CRef.  LOU 


3 .   D  a  t  a  D  .1  c  t  i  o  n  a  r  y 

There  are    basically  tour  classes  of  data 
environments.   Early  programming  methods  involved  only  the 
first  class:  files.   The  second  class,  application  data 
bases,  include  data  bases  designed  +  or  separate 
applications.   The  third  and  fourth  classes,  subject  data 
bases  arad  information  systems,  require  an  enormous  amount  of 
sharing  of  data  attributes  and  if  uncontrolled  can  become 
unmanageable,   The  purpose  of  a  data  dictionary  is  to 
control  that  data.   James  Martin  defines  a.  data  dictionary 
as  "  a  tool  which  lists  all  fields  that  are    used,  their 
definitions,  how  and  where  they  are    used,  and  who  is 
responsible  for  them.   All  fields  in  all  locations  are    in 
the  data  d  1  c  1 1  o  nary."  II R  e  f  .  1  1  ]    T  h  e  d  a  t  a  a  d  m  i  n  1  s  t  r  a  t  o  r 
needs  the  data  dictionary  to  enforce  agreement  on  the 
definiti  o  n  o  f  e  a  c  h  fie  1  d  in  o  r  d  e  r  to  e  n  s  u  r  e  c:  o  m  p  a.  t  i  b  1 1  1 1  y  o  f 
t  h e  d  a  t  a  t  h  r  ou g  h  o u  t  the  c  o r  p  o r  a  t i o n . 


4 .-,   I...I  s  e  r  I  n  v  o  1  v  e  m  e  n  t 

A n  o  t  h  e r  m  a  j  or  d  1  f  f  e  r  e n  c  e  b  e  t  w e e  n  t  r  a  d  1  t  i  o  n  a  1 
software  development  techniques  and  information  engineering 
is  the  degree  of  user  involvement.   In  the  past,  the  user 
filled  out  a  form  stating  his  application  requirement  and 
sometime — on  the  average  of     three  or    four  years  later  —  a 
piece  of  output  might  show  up.   But  in  in  format  ion 
engineering,  the  user  is  directly  involved  in  each  of  the 


stages.   For  instance,  in  strategic  requirements  planning, 
senior  management  must  be  involved  to  ensure  the  correct 
objectives  and  direction  of  the  organization  for  the  future 
are    properly  communicated.   In  information  analysis,  the 
user  is  primarily  responsible  for  the  completeness  and 
accuracy  of  the  organizational  data  base.   Finally,  in 
application  development  without  programmers,  the  user 
creates  and  utilizes  the  applications  he  needs  to  get 
results.   This  method  of  user  involvement  leads  to  a  more 
flexible  environment  in  which  changes  can  be  made  easily  and 
quic k 1 y , 

5.   Six  Stages  of  Growth  in  Data  Processing 

A  final  differentiation  between  the  data-oriented 
analysis  of  information  engineering  and  the 

procedure-oriented  analysis  of  software  engineering  can  be 
shown  by  discussing  the  effects  of  the  six  stages  of  growth 
i  n  d  a  t  a  processing  i d entified  b y  R i c  h a  r  d  N o 1  a n  a n d  s h o w n  i n 
F i g u re  4  C R e f „  123.   D u r  i  n g  t he  f  i r s t  t w o  s t a g e s ,  i n i t i  a t  i o n 
and  contagion,  the  data  processing  department  is  concerned 
with  automating  functional  cost  reduction  applications  of 
specific  areas  such  as  ace o u n t i n g  o r  i n v e n t o r y  c o n t r o 1 .   I f 
ail  goes  well,  additional  requirements  ar^t    considered. 
During  the  t h i r d  s t age,  c o n t r o 1 ,  the  D P  d e p a r t m e n t  finds 
itself  unable  to  keep  pace  with  requirements.   Often  this  is 
caused  by  the  lack  of  an  overall  plan  throughout  the 


corporation  for  utilizing  data  processing.   During  the 
control  phase,  management  upgrades  documentation  and 
requires  formalized  justification  for  future  applications. 
Integration  is  the  fourth  phase  and  is  marked  by  a 
fundamental  change  in  the  way  applications  arte  developed.- 
Data  is  consolidated.   In  the  fifth  stage,  data 
administration,  the  organization  has  a  wel 1 -devel oped  data 
base.   In  the  final,  stage,  maturity,  the  data  processing 
function  "mirrors"  the  way  the  organization  operates  and  all 
is  right  in  the  world. 

Organizations  in  stage  1  or  2  c^n    successfully 
utilize  procedure-oriented  analysis  and  design  techniques. 
A  more  mature  organization  must  use  the  data-oriented 
technigu.es  because  procedure-oriented  techniques  make  it 
virtually  impossible  to  identify  data  redundancy  which 
exists  thro  u  g  h  o  u  t  t  h  e  <::>  r  g  a  n  i  z  a  1:  i  o  n  , 
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!   g urs  4  -  Stages  of  growth  in  data  processing  [Ref.  12.1 


6.   Summary 

The  traditional  methods  o-f  software  development  are 
still  important  to  smaller  applications  and  to  organization? 
just  beginning  to  utilize  data  processing.   Information 
engineering  was  not  created  to  replace  those  methods.   The 
primary  goal  o-f  information  engineering  is  to  give  larger 
organizations  the  capability  to  design  data  processing 
systems  that  support  the  organization's  objectives  and 
capitalize  on  the  value  o-f  the  data  resource.   Corporations 
such  as  Exxon  and  government  agencies  such  as  the  Naval 
Supply  Systems  Command  have  endorsed  the  concept  of 
i  nf  ormat 1  on  eng 1 neer  i  ng  and  btq    current  1 y  i  n vol ved  i  n 
projects  based  on  its  methodologies.   The  "mature" 
organization  of  the  future  is  closer  to  becoming  a  reality. 


IV.   DATA  ADMINISTRATION  AND  VERTICAL  INTEGRATION 

A.   OVERVIEW 

The  design  of  modern  information  systems  is  far  more 
complex  thiin  any  project  most  organizations  have  previously 
attempted.   As  an  organization  moves  through  Nolan's  stages 
of  ADR  evolution,  it  is  more  difficult  to  change  its  ADR 
structure  to  fit  its  information  needs.   No  simple  tools 
e  >;  i  s  t  t  o  a  s  s  i  s  t  c  o  r  p  o  r  a  t  e  m  a  n  a  g  e  r  s  i  n  p  1  a  n  n  i  n  g  t  h  e 
transition  to  the  next  phase.   Techniques  such  as  lite  cycle 
planning,  stages  of  growth.  Business  Systems  Planning  and 
critical  success  -factors  all  lack  some  integral  elements  and 
ans    not  totally  effective  in  today's  highly  technical, 
complex  information  world  CRef.  133.   Information 
Engineering  is  the  latest  attempt  at  successful  planning  of 
i n  f  o r  m a t  i o n  needs. 

A  n  organ  3.  z  a  t  i  o  n  c  a  n  n  o  t  r  e  1  y  s  o  1  e  1  y  o  n  t  h  e  c  o  n  c  e  p  t  s  o  f 
I  n  f  o  r  m  a  t  i  o  n  Engineer!  n  g  i  n  ere  a  ting  i  n  f  o  r  m  a  1 1  o  n  s  y  stems.   IE 
should  be  viewed  as  the  nucleus  of  a  variety  of  data 
processing  tools  or  techniques  that  when  thoughtfully  " 
integrated  furnish  the  organization  with  an  effective  system 
that  handles  informati o n  need s  n o w  a n d  w i 1 1  a 1 1 o w  s u f f i c i e n t 
e ;••:  p a n s i  on  t  o  m e e t  all  f  u t u r e  r e q u i  r  e m e n t  s «   T he  f  o  1 1  o w i  n q 
are  some  of  the  many  components  of  a  complete  information 
system  as  shown  in  Figure  5: 
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Figure  5  -  Components  of  Information  Engineering 
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1.  Information  Centers 

2.  Fourth  Generation  Languages 

3.  Expert  Systems 

4.  Computer  Graphics 

5.  Programming  Languages 

6.  Database  Management  Systems 

7 .  D  a  t  a  D  i  >::  t  i  o  n  a  r  i  e  s 
3,  Data  Administration 

Most  of  these  components  am    software  tools  that  aid  the 

system  developers  or    allow  easier  retrieval  of  data  by  the 

users™   The  last  component.  Data  Administration,  is  a 

collection  of  management  functions  that  when  properly 

per+ormed  significantly  ease  the  effort  required  in  an 

Information  Engineering  project. 

B.   DATA  ADMINISTRATION  FUNCTIONS 

Data  Administration  is  best  described  as  the 
responsibility  for  planning,  coordinating,  and  managing  an 
organisation's  data.   Basic  functions  to  support  that 
r  e  s  p  o  n  s  i  b  i  1  i  ty  h  a  v  s  e  v  o  1  v  e  d  f  r  o  m  a  d  m  i  n  i  s  t  r  a  t  i  v  e  a  n  d 
t e c h n i c a 1  i  s s u e s  i n v o 1 v e d  w ith  d a t a  base  a d m i n i s t r a t i o n . 
The  concept  of  Data  Administration  is  less  than  ten  years 
old  and  is  tar    from  being  a  defined  entity.   Most 
definitions  of  Data  Administration  embrace  at  least  five 
areas:  strategic  data  planning,  data  modeling,  data 
conventions  and  standards,  data  interchange  and  tools 
management.   An  over" all  goal  should  be  the  establishment  of 
policies  and  guidelines  for  the  management  of  data  as  a 
valuable  corporate  resource =   The  following  list  of    duties 
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of  a  data  administrator  is  representative  of  those  -found  on 
position  descriptions  for  a  variety  o-f  companies. 


Manages  the  development  o-f  standards,  methods,  and 
guidelines  -for  data  planning,  analysis,  data  modeling, 
documentation,  and  logical  database  design. 

Manages  the  coordination  between  users,  project 
management,  analysts,  and  management. 

Manages  the  logical  database  designs  and  the  use  of 
logical  design  software. 

Manages  the  establishment  of  the  Data  Dictionary  and 
develops  standards  i-or    its  use. 

Plans  and  manages  the  education  of  the  staff  on  data 
planning,  analysis,  modeling,  documentation,  and 
logical  design. 

Manages  the  staff  in  providing  data  modeling  support 
to  ail  project  team  system  development  efforts, 

Provides  logical  database  designs  and  performance 
specifications  to  database  administration  and  verifies 
any  required  database  design  changes  for    the  project 
and  user  management. 

Provides  an  awareness  of  contemporary  methods  of  data 
modeling  and  evaluates  their  application  in  the 
current  organisational  setting.. 

Manages  the  security  and  p r i v a c y  of  the  d a t  a  i  n  a  1  1 
logical  design, 

Manages  the  maintenance  of  the  strategic  plan. 

Provides  the  resolution  of  all  data  definition  ana 
usage  issues. 


Originally,  data  administration  was  thought  of  as  a 
p  u  r  sly  technic  a  1  f  u  n  c  1 1  o  n  h  a.  v  i  n  g  p  r  i  m  a.  r  y  r  e  s  p  o  n  s  l  b  i  1  i  t  v  o  v  e  r 
the  effectiveness  and  efficiency'  of  data  bases  and  database 
management  systems  (E»BMS)  [Ret.  143.   However,  corporations 
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soon  found  that  merely  appointing  someone  to  be  in  charge  of" 
data  bases  left  a  void  in  the  overall  management  of  data. 
The  data  administrator  definitely  needs  to  possess  two  types 
of  talents  administrative  and  technical. 

Administrative  skill  is  required  to  handle  management 
and  policy  affairs,  to  interact  with  various  groups  of 
concerned  and  affected  people,  and  to  define  what  should  be 
in  the  organization's  data  bases.  The  technical  skills  ars^ 
required  to  determine  implementation  issues  relevant  to  the 
specific  data  bases  and  to  define  how  the  organization  data 
bases  will  be  structured  and  accessed. 

The  functions  of  data  administration  (DA)  ar<B    often 
combined  with  those  of  database  administration  (DBA)  in 
organizations  where  the  same  person  performs  both  sets  of 
f  u r l c t  i  o n s .   M any  o r q a n i z  a t i  o n s  c o n s i  d e r  t he  DA  to  be  si m p 1 y 
t h  e  chief  D B A .   F o r  those  o r  g  a  n i z  a  1 1 o n s  m o v  i n g  tow  a  r  d  s  t h e 
m a t  u r  :i.  t  y  p h a. s e ,  c o m b  i  n  i  n g  D a t  a  A d m i  n  i  s t  r  a 1 1  an  an d  d a t  a b a s e 
administration  functions  is  not  realistic,   Those 
o r g a n :i.  z a t i  o n s  r squire  the  DA  t o  h a v e  e x t e n s i  v e  k n o w  1  e d g e  o f 
the  organization  and  its  overall  composition.   For  instance, 
in  Information  Engineering,  the  Data  Administrator  would  be 
fully  involved  in  the  first  three  steps;  strategic 
r  e  q  u  i  r  e  m  e  n  t  s  p  1  a  n  n  i  n  g  ,  i  n  f  o  r  m  a  t  i  o  n  a.  n  a  1  y  sis,  a  n  d  d  a  t  a 
m  o  d  e  1  i  n  g  .   T  h  ere  a  r  e  f  e  w  d  a.  t  a.  b  a  s  e  a  d  m  i  n  i  s  t  r  a  t  o  r  s  t  h  a  t 
possess  the  necessary  skills  to  properly  execute  those 
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functions  as  well  as  have  the  time  to  adequately  control  the 
data  bases. 

The  combination  of  these  skills  or  rather  the  lack  of 
combination  often  determines  the  placement  of  the  data 
administration  function  within  the  organisation's  structure. 
When  a  data  administration  shop  is  just  beginning  it  is 
often  placed  lower  in  the  organisational  heirarchy  because 
upper  management  is  unsure  of  the  technical  aspects  of  its 
data  bases.   However,  to  ensure  better  data  consistency 
throughout  the  organization,  it  is  better  to  separate  the 
functions  of  the  data  administrator  from  the  database 
administrator  and  place  the  DA  function  high  enough  in  the 
organizational  chain  to  be  effective  in  policy  matters  that 
affect  information  systems. 

C.  DATA  ADMINISTRATION  VS.  DATABASE  ADMINISTRATION 

Figure  £>  shows  a  comparison  of  data  administration  and 
database  administration  concerns  [Re-f ,  153.   The  basic 
difference  involves  interfacing  with  a  particular  data  base 
v ice  s t r u c t  u r i n g  d a t  a  i n dependen t  o f  a  d a t  a  b a s e .   D a t  a 
administration  must  be  concerned  with  the  long  term  design 
needs  and  utilizes  the  data  dictionary  as  a  primary  tool. 
The  data  administrator  has  the  overall  responsibility  for 
the  o  r  g  a.  n  i  z  a  1 1  o  n  :'  s  d  a  t  a  r  e  s  o  u  r  c  e  s ,  a  n  d  i  s  r  e  s  p  o  n  s  i  b  1  e  f  o  r 
n  o  n  t  e  c  h  n  3.  c  a  1  a.  c  1 1  v  i  t  i  e  s  s  u  c  h  a.  s  p  1  a  n  n  i  n  g  a  n  d  d  e  f  i  n  i  n  g  t  h  e 
conceptual  framework  for  the  overall  database  environment ? 
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not  just  that  specifically  limited  to  DBMS  usage,   Database 
administration  is  concerned  with  the  efficiency  of  the 
actual  database  structure  and  DBMS.   The  DBA  is  the 
organization's  leading  technical  expert  on  database  related 
activities  and  is  reponsible  for  the  day-to-day  operation  of 
all  database  related  activities.   He  is  involved  with  the 
daily  decisions  and  activities  which  have  immediate  impact 
upon  the  organization's  operational  data  bases.   The  DBA  is 
not  overly  concerned  with  data  modularity,  ex tendabi 1 i t y ,  or 
utility.   Data  modularity  is  the  ability  of  a  data  structure 
to  accommodate  more  easily  changes  to  the  information 
requirements  of  the  organization.   Data  ex tendabi 1 i ty  is  the 
ability  of  the  data  structure  to  accommodate  additions  or 
deletions  to  instances  of  data  without  affecting  the  design 
of  the  structure  or  the  programs  that  use  the  data.   Data 
utility  is  the  ability  of  a  data  structure  to  satisfy  the 
information  needs  of  a  variety  of  end  users. 
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DATA  ADMINISTRATION  VS.  DATA  BASE  ADMINISTRATION 
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D.   DATA  ADMINISTRATION  AT  NAVSUP 

In  November  1984,  NAVSUP  reorganized  the  Inventors'  and 
Information  Systems  Directorate  (SUP-04)  in  a  move  to  help 
gain  control  over  current  and  future  systems  development,   A 
major  point  prompting  the  reorganization  was  the  tact  that 
NAVSUP  was  supporting  development  ot  separate  information 
systems  without  any  integration  between  those  systems.   As 
part  of  the  reorganization  of  SUP— 04,  a  data  administration 
branch  was  created  (SUP— 0414)  as  part  of  the  Information 
Systems  Management  and  ADP  Security  Division.   Its  primary 
objective  is  to  develop  a  corporate  data,  plan  and  logical 
data  model  for  NAVSUP  that  will  maximize  sharing,  minimize 
redundacy  and  coordinate  all  data,  flow  within  the  Naval 
Supply  System  and  its  interfaces  with  external  systems. 

The  majority  of  the  Data  Administration  Branch's  effort 
to  date  has  been  with  defining  goals  and  implementing  the  DA 
function  at  NAVSUP.   The  branch  has  created  the  following 
objectives  and  a  timetable  for  the  next  two  vears: 

Mar  86    IMPLEMENT  THE  DATA  ADMINISTRATION  FUNCTION 

Staffing  POM  and  Recruitment 
N  A  V  S U  P  C  o  r  p  o rate  R  e  g u  i  r e m en  t  s 
Mission  Statement 
Policy  and  Procedures  Statement 
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June  86   DEFINE  AN  OVERALL  INFORMATION  SYSTEM 
ARCHITECTURE  TO  SUPPORT  NAVSUP  BUSINESS 
FUNCTIONS 

De-fine  Current  Initiatives 
Create  NAVSUP  S t eennq  Comm  1 1 1  ee 
Develop  NAVSUP  Business  Model 
Develop  Information  Architecture 

Dec  86    DEVELOP  DATA  ARCHITECTURE  TO  SUPPORT  THE 
NAVSUP  INFORMATION  SYSTEMS  ARCHITECTURE 

Design  NAVSUP  Logical  Data  Model 
Develop  Corporate  Data  Dictionary 

Jun  37    DEVELOP  A  NAVSUP  TECHNICAL  PLAN 
ENCOMPASSING  TELECOMMUNICATIONS,  OFFICE 
AUTOMATION,  AND  OTHER  EXISTING  NAVSUP 
INITIATIVES 

Document  Systems  Hardware  and  Software 
Develop  Systems  Concept  Paper 
Perform  Input  Analysis 
Develop  Technical  Plan 

The  above  objectives  support  goals  of  (1)  developing  the 

overall  objectives  of  the  data  administration  function  and 

secure  their  endorsement  by  top  management;  (2)  determining 

NAVSUP' s  DA  scope,  in  terms  of  both  subject  matter,  and 

o r g a n i z a t  i  o n a  1  c o m p o n en t s  a n <: i  p r o q r ■  a m s ;  ( 3 )  a s s i g n in g 

o v e r  a  1  1  a. u thonty  a n d  r e s p o n s i  b  i  I  i  t  v  |j  a n d  ( 4 )  p r o m u I  g a t  i  n g 

ov&r  all  or  q  a n  i  national  p o  1  i  c  y .   Ac  c  or  d  i  n g  t  o  i.  t  s  m  i  s s i  on 

statement,  the  data  a.  d  m  i  n  i  s  t  r  a  t  i  o  n  branch  i  s  d  e  d  i  c  a.  t  e  d  t  o 

providing  a  systematic  plan  for    developing  standards  and 

policies  which  ensure  ultimate  vertical  and  horizontal 

integration  of  data  among  the  various  NAVSUP  and  external 

i  n  f  o  r  m  a  t i o n  s y  stems. 
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Although  the  branch  has  been  poorly  staffed  since  its 
inception,  a  considerable  amount  of  headway  has  been  made 
towards  achieving  its  first  year  goals.   An  initial  decision 
has  been  made  for  SUP-0414  to  be  the  proponent  for  all 
NAVSUP  information  resources  and  to  develop  the  DA  plan 
while  FMSO  is  being  tasked  to  accomplish  the  DA  tasks,   The 
following  is  a  list  of  SUP-0414  and  FMSO  functions  as 
currently  defined: 

SUP-0414  FUNCTIONS 

1.  Develop  and  maintain  a  NAVSUP  Corporate  Data  Plan 
and  Logical  Data  Model  to  reflect  the  data 
structures  required  to  support  the  information 
requirements  of  the  Naval  Supply  System, 

2,  Initiate  and  develop,  in  coordination  with  the 
Planning  and  Policy  Branch,  NAVSUP  standards  and 
procedures  related  to  data  resource  management, 
including,  but  not  limited  to.  Data  Dictionary 
Specification  Standards  and  Data  Element  Naming 
Convent i ons. 

3.  Serve  as  NAVSUP  arbiter  to  review  and  resolve  data 
resource  issues  within  ADP  program  development, 

4,  Review  Data  Communication  Requests  to  insure 

c  o  m  p  1  i  a  nee  with  Data  A  <  j  m  i  n  i  s  t  r  a  t  i  o  n  S  t  a  n  d  a  r  d  s  a  n  d 

Procedures, 

5 »   D  e  v  e  1  o  p  a  n  d  i  m  p  1  e  m  en  t  D  a  t  a  E 1  e  m  e  n  t  N  a  m  i  n  g 

Standards  and  Policies  for  all  NAVSUP  ADP  systems, 

6,  Develop  policy  and  procedures  for  data  transfer 
across  all  !'•  J  A  V  S  U  P  n  e  t  w  o  r  k  s ,  i  n  c  1  u  d  i  n  g  d  a  t  a 

d own load  to  mi cr oc ompu t er s . 

7,  Manage  development,  implementation,  and 

m  a i  n  t e n a n c  e  of  the  C o r  p o rate  D a  t  a  D i c  1 1 o n a  r y , 

8,  Act  as  NAVSUP  1 i ason  with  all  external  data 

s  y  s  t  e  m  ??  w  i  t  h  i  n  N  a  v  y ,  D  0  D ,  a  n  d  c  i  v  i  1 1  a  n  a  g  e  n  c  i  e  s 
a n d  d a t a  s t a n d a r d izat i  o n  e f f o r t s , 
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9.  Review  System  Life  Cycle  Maintenance  Documentation 
-for  adherence  to  Data  Administration  Policies  and 
Procedures. 

10.  Develop  policy  and  standards  for  logical  data  base 
design  for  all  NAV'SUP  system  development  projects. 
Conduct  post  implementation  reviews  to  insure 
compliance  to  standards. 

11.  Develop  NAV'SUP  policy  and  standards  for 
initiatives  that  access  any  data,  base,  both 
Corporate  and  private. 

FMSO  Functions 

1.  Perform  system  planning. 

2.  Provide  access  procedures  and  monitoring  for  all 
databases. 

3.  Perform  data  and  impact  analysis. 

4.  Assist.  NAV'SUP  DA  Branch  in  determining 
Headquarter ' s  Corporate  data  requirements. 

5 .  Provide  input  to  p o 1  icy. 

6.  Implement  corporate  data  model. 

7.  Determine  and  maintain  a  record  of  relationships 
among  databases. 

8.  Develop  corporate  data  dictionary. 

^ .,   Monitor  quality  and  integrity  of  data. 

1 0 .  F u n c  t  i o n  a s  technical  DA  exper t . 

11.  Establish  documentation  standards  for    database 
systems. 

12.  Conduct  formal  DA  training. 

13.  Evaluate  various  automated  tools  for  DA 
devel op ment . 

14.  Serve  a  s  p  r  i  n  c  i  p  1  e  c  o  n  s  u  1 1  a  n  t  o  n  d  a.  t  a  b  a  s  e  d  e  s  i  g  n 
p  r  o  j  e  c  t  s  a  n  d  a  u  d  1 1  i;  r  a  i  .1  s . 
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From  the  above  lists,  it  can  readily  be  seen  that  5UP-0414 
has  a  good  idea  of  what  it  wants  to  accomplish  but  must  rely 
heavily  on  FMSO  to  do  so.   What  remains  to  be  seen  is  how 
much  top  management  support  SUP— 0414  will  be  given.   The 
next  step  tor  NAVSUP' s  Data  Administration  Branch  is  to 
develop  the  NAVSUP  DA  Directive  to  outline  all 
responsibilities  and  establish  its  corporate  policy. 

E.   DATA  ADMINISTRATION  AND  VERTICAL  INTEGRATION 

One  of  the  goals  formulated  by  NAVSUP  in  its  strategic 
plan  is  to  "Develop  databases  which  support  the  single 
update  of  related  data  and  provide  the  required  views  o-f 
that  data  to  all  levels  of  the  work  force"  L'Ref  163.   To 
achieve  that  goal  requires  the  integration  of  NAVSUP' s 
information  systems  both  vertically  and  horizontally,   In 
relation  to  the  three  information  systems  discussed,  SUADPS 
R E A L - T I !i E ,  U A D P S - S P  a n d  U I C P ,  v e r 1 1  c a  1  integration  i  n v o  1  v e s 
t r a n s f e r r i n g  informati o n  f r o m  o n e  s y ste m  t o  another,  ie. , 
from  ship  to  stock  point.   Horizontal  integration  involves 
passing  information  from  organization  to  organization  on  the 
same  level,  ie. .  from  stock  point  to  stock  point, 

Integration  of  information  systems  requires  compatible 
hardware  and  software  and  we 1 1 - d e  v e 1 o p e d  d a t  a  b  a  see,   N A V S U P 
has  addressed  the  problem  of  hardware  and  software 
c  o  m  p  a  1 1  b  i  1  i  t  y  a  n  d  i  n  c  I  u  d  e  d  t  h  o  s  e  r  e  q  u  i  r  e  m  e  n  t  s  i  n  t  h  e 
specifications  for  the  SPAR  system  acquisition..   Indeed,  the 
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technology  to  allow  communication  between  the  three  systems 
exists  today.   Additionally,  at  the  completion  of  the  SPLICE 
project,  the  capability  tor  UADPS-SP  systems  to  communicate 
through  the  DDN  will  be  achieved.   However,  compatible 
systems  cannot  overcome  weaknesses  in  data  organization. 
How  valuable  is  having  integrated  information  systems  if  the 
needed  data  does  not  exist,  or    no  one  knows  whether  the  data 
is  available  or  not,  or    if  conflicting  data  exists,  or  if 
effective  controls  over  the  use  of  the  data  are    lacking? 
The  above  weaknesses  exist  in  most  organizations' 
information  systems  and  ar<a    the  primary  focus  of  data 
ad mini  strati  on. 

NAv'SUP  headquarters  has  a  definite  problem  with 
integrating  its  three  information  systems  because  its 
overall  ADP  environment  has  never  existed  in  stages  4  and  5 
of  Nolan's  cycle;  Integration  and  Data  Administration. 
These  two  stages  are    characterized  by  the  integration  of 
applications  vice  information  systems  and  by  the  development 
and  management  of  data  bases.   All  of  NAV'SUP :'  s  previous 
s  y  s  t  e  m  s  utilized  file  s  t  r  u  c  t  u  r  e  s  base  d  o  n  a  p  p .!.  i  c  a  1 1  o  n  s , 
SUADPS  REAL-TIME  has  retained  its  redundant  file  structures, 
UICP  RESYSTEMIZATION  is  being  designed  around  its  current 
applications.   The  redesign  of  UADPS-SP  is  NAV'SUP' s  first 
attempt  at  using  modern  database  structures  and  database 
m a n a q e m en t  s y s t  e m s  as  w ell  a s  r e s t r u c  t  u r i n g  a p p 1 i  c a t i  o n s , 
NAVSUP  is  therefore  having  to  move  through  two  phases  to 
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catch  up  to  today's  technology.   This  is  primarily  due  to 
the  requirement  for  NAVSUP  to  keep  its  original  systems 
throughout  the  period  that  comparable  organisations  were 
implementing  data  base  systems.   Another  negative  factor  is 
the  decentralised  environment  in  which  the  NAVSUP  systems 
have  evolved.   For  two  decades,  the  coordination  of  the 
three  systems  at  the  ship,  stock  point,  and  TCP  level  was  a 
low  priority  at  headquarters. 

In  an  effort  to  support  the  goal  of  integrated 
information  systems,  NAVSUP7 s  strategic  plan  requires  the 
establishment  of  a  formal  SPAR/ICP  RESOL I CTAT I ON/ SUADPS 
application  working  group  to  identify  and  justify 
integration  opportunities.   Although  it  initially  restricts 
the  concept  of  integration  to  the  three  current  systems  and 
their  current  applications,  it  is  a  beginning.  For  this 
integration  team  to  be  effective,  it  should  be  relatively 
!.  n  d  e  p  e  n  d  e  n  t  o  f  t  h  e  m  a  n  a  g  e  m  e  n  t  h  i  e  r  a  r  ■::  h  y  i  n  o  r  d  e  r  t  o  a  v  o  i  d 
the  power  struggles  of  each  of  the  current  systems  and  to 
escape  the?  risk  aversion  attitude  of  corporate  headquarters, 
The  accessibility  of  data  creates  a  multitude  of  questions 
regarding  NAVSUP' s  traditional  support  structure,   The 
business  of  providing  supply  support  to  the  operating  units 
of  the  Navy  remains  the?  same.-,   However,  NAVSUF  should  t.ske 
a d v a n t a g e  o f  t echnolog i  c a 1  a d v a n c e s ,  1 o o k  a t  t h e  c u r r e n t 
automated  applications  and  functions,  and  ask  whether  it  can 
be  done  better  with  new  technology.   For  instance,  if  a  ship 


has  access  to  the  worldwide  inventory  of  parts,  does  it  need 
to  submit  a  referrral  to  the  closest  stock  point  if  it  is 
not  carried  there?   Why  not  refer  the  requisition  to  the 
stock  point  or  activity  that  has  the  part  available  and 
avoid  the  additional  referral  to  the  ICF"?   In  a  segregated 
information  organization,  the  answer  would  be  because  that 
function  does  not  exist  at  the  shipboard  level.   It  is  the 
ICP's  responsibility.   Finding  the  optimum  solution  to 
questions  created  by  the  new  availability  of  data  will  be 
difficult  at  best.   It  requires  a  total  rethinking  of  the 
processes. 

Many  of  the  questions  that  the  integration  team  will 
address  should  have  been  answered  prior  to  the  beginning  of 
the  UICP  RESYSTEMIZATION  project  or    at  least  the  Information 
Engineering  portion  of  the  SPAR  project.   An  example  is  the 
interfaces  needed  between  the  three  current  systems.   That 
guidance  should  have  originated  from  headquarters  as  part  of 
a  top-down  planning  technique  of  the  strategic  requirements- 
phase.   The  redesign  team  at  FMSO  used  a  bottom-up  approach 
to  define  the  probable  interfaces.   No  decision  has  been 
made  about  whether  all  the  interfaces  ar^    correct  and 
complete.   In  the  meantime,  FMSO  is  beginning  to  feel  the 
pressure  of  command  dictated  completion  dates. 

The  objectives  of  Data  Administration  support  the  goal 
of  integrated  information  systems.   Data  is  the  most 
important  component  of  information  systems.   The  key  is 


knowing  what  data  exists  and  where  it  is  located.   The 
functions  o-f  the  DA  include  developing  and  maintaining  a 
data  dictionary  which  can  answer  queries  regarding 
information  resources.   For  instance,  it  NAVSUP  needed  to 
know  the  data  entities  and  applications  containing  standard 
MILSTRIP  requisition  information  such  as  QUANT I TY-QN-ORDER , 
the  E'ata  Administrator  should  be  able  to  respond  with 
information  detailing  the  fact  that  QUANTITY-ON-ORDER  is 
represented  by  six  different  variable  names  in  23  different 
programs  and  be  able  to  list  them.   Data  dictionary 
information  is  extremely  valuable  in  systems  integration. 
Therefore,  the  integration  team  should  study  the  overall 
Data  Administration  organization  at  NAV'SUP  to  help 
understand  the  complexities  of  structuring  data  to 
facilitate  system  interfaces,   NAV'SUP  may  have  begun  its 
Data  Administration  program  too  late  to  play  out  its 
complete  role  in  the  information  engineering  project  for 
SPAR,.-   However,  NAVSUP  is  not  just  in  the  business  of  supply 
support;  it  is  also  involved  in  retail  operations, 
p  e  t  r  o 1 e u m ,  household  goods  s h i  p  m e n  t  s  a n  d  m a  n  y  o t  h e  r 
information-dependent  functions.   The  establishment  of 
effective  integrated  systems  in  one  arc-a    may  pave  the  way 
for  additional  improvements  in  other  information  systems. 


F.   PROBLEMS  WITH  DATA  ADMINISTRATION  AT  NAVSUP 

The  establishment  of  the  data  administration  function  at 
NAVSUP  is  now  at  a  crossroads.   The  definition  of  goals  and 
objectives  for  DA  ^.r&    relatively  complete.   Implementation 
of  those  objectives  and  achieving  the  goals  will  not  be  as 
easy.   Top  management  at  headquarters  must  dedicate  support 
and  make  a  decision  regarding  the  scope  of  the  DA  function 
to  give  the  Data  Administration  Branch  the  power  it  needs  to 
fulfill  its  responsibilities.  SUP-0414  has  encountered  many 
of  the  same  problems  in  establishing  the  data  administration 
function  as  its  counterparts  in  other  large  corporations. 
Among  those  avs    lack  of  expertise  and  resistance  to  change. 
Other  problems  such  as  the  budget  constraints  for  the  DA 
evolution  ar??    unique  to  a  military  or  government 
environment.   The  following  is  a  list  of  factors  that  ar& 
currently  hindering  the  proper  development  and  effectiveness 
of  the  data  administration  function  at  NAVSUP; 


1.  Incomplete  staffing  of  DA  Branch!   The  current 
plan  allocates  three  positions  in  3UP-0414,   Only 
one  position  remained  filled  for  the  past  10 
months  and  it  is  now  vacant.   Recruitment  does  not 
seem  to  be  a  top  priority. 

2.  Limited  ADP  background  of  staff;   The  one  staff 
member  previously  employed  devoted  the  majority  of 
her  time  getting  up  to  speed  on  ADP  terminology 
and  database  techniques.   This  has  resulted  in  a 
lack  of  credibility  with  the  principal  players  at 
FMSO  and   the  information  systems  sponsors  at 
NA'-'SUP, 

3 .  The  D A  Bra n c h ' s  I o cation  in  N A V S U P ' S 
organizational  structure  is  too  low  to  solicit 


cooperation  from  information  systems  sponsors: 
SUP-0414  is  competing  against  the  firmly 
entrenched  support  structures  of  the  three  current 
information  systems.   DA  objectives  which  require 
a  rethinking  of  application  functions  ar& 
unachievable  in  the  current  structure  without 
power  struggles. 

4.  Attempting  to  establish  a  DA  environment  in  a 
d  scent  r  a  1  i  z  ed  ADP  en  v  i  r  on  men  t :   NAV'SUP 
headquarters  has  no  control  over  the  data  or  the 
applications  development  of  its  information 
systems.   Data  is  processed  around  the  world  while 
the  design  and  development  of  the  three 
information  systems  is  accomplished  by  two 
separate  activities.   Implementing  data  standards 
will  be  more  difficult  than  if  NAV'SUP  functioned 
under  a  centralized  ADP  concept. 

5.  Attempting  to  implement  DA  functions  in  time  to 
determine  data  needs  for  SUADPS  REAL-TIME/  SPAR/ 
UICP  interface:   If  data  administration  is  to 
effectively  support  the  information  engineering 
concept,  data  needs  and  interfaces  must  be 
determined  prior  to  system  design.   SUP-0414  is 
way  behind  the  power  curve  regarding  the  current 
development  of  information  systems,   The  needs  of 
the  three  projects  may  be  dictating  the  DA  efforts 
instead  of  the  true  needs  of  the  corporation. 

6.  Corporate  inexperience  with  database  management: 
Data  administration  functions  evolved  from 
database  administration.   It  is  difficult  to 

determine  long  range  and  overall  data  needs 
without  experience  with  designing  and  operating 
spec i f  i  c  dat  abases . 

7 »   Data  A  d  ministra  t  i  on  c  o  n  f  1  i  c  t  s  w  i  t  h  1:  h  e  t  r  a  ditional 
organizational  philosophy  of  NAV'SUP:   Headquarters 
is  uncomfortable  with  the  concept  of  DA  because  it 
is  historically  a  r e a c 1 1 v e  o r  r i  s k  a v e rsion 
centered  organization,   The  lack  of  ADP  oriented 
personnel  at  headquarters  restricts  the  knowledge 
of  information  engineering  and  the  value  of 
wel 1 -integrated  data. 

S ,   C u. r r en t  time  s c h e d u  I  e  f  o r  a c h  i  e v  i  n q  DA  f  u n c  t  i  o n  s 
waits  too  long  before  tangible  benefits  ^.r^ 
a c  h  i  e  v e d :   An  o r  g  a n  i  z  a t  i  o n  s u c  h  a  s  N A V S U P  n  e e d  s  t  o 

see  tangible  benefits  in  order  to  justify  the 
expense  of  the  DA  function.   In  the  government, 


this  is  especially  a  problem  clue  to  the  budget 
process  and  current  deficit  spending  concerns. 

The  above  problems  are    by  no  means  fatal  to  the  data 

administration  function.   However,  collectively  they 

critically  restrict  the  evolution  of  the  DA  function  at 

NAVSUP,   if  NAV'SUP  is  serious  about  providing  integrated 

data  throughout  its  organisation,  then  it  must  dedicate  top 

management  resources  to  solve  these  problems,   SUP— 0414  has 

identified  the  needed  tasks.   Hcwever ,  no  real  authority 

exists  to  ensure  they  are    performed. 
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V .   CONCLUSIONS 

The  world  of  information  systems  design  has  undergone  a 
remarkable  change  since  NAVSUP  first  implemented  SUADPS, 
UADPS-SP  and  UICP.   Unlike  many  corporations  which  have 
implemented  database  systems,  NAVSUP  is  not  afforded  the 
opportunity  to  make  an  easy  transition  from  the  application 
centered  projects  to  the  concept  of  information  engineering 
and  integrated  systems.   Data  Administration  is  one 
management  function  that  can  allow  NAVSUP  to  eventually 
catch  up  with  its  information  needs  if  it  is  given  enough 
support . 

The  UADPS-SP  redesign  effort  will  be  the  key  to  NAVSUP 
having  integrated  information  systems.   SUADPS  REAL-TIME  and 
UICP  have  already  been  committed  to  application-dependent 
file  structures.   UADPS-SP  will  be  the  prime  interface 
vehicle  for  the  integration  of  data.   The  FNSO  UADPS-SP 
Redesign  Team  has  taken  the  lead  in  performing  the  strategic 
requirements  function  of  information  engineering.   It  must 
be  completed  prior  to  the  design  of  the  logical  database 
s tructure.   N A V S U P  s hi o u  1  d  r e s p o n d  as  s o o n  a s  p o s s  1  b  1  e  to 
their  queries  regarding  the  desired  functional  activities  of 
UADPS-SP. 

A  side  f  r  o  m  p  r  o  v  i  d  i  n  g  t  o  k  e  n  i  n  p  u  t  r  e  g  a  r  d  i  r  "i  g  n  a  m  i  n  q 
s t  a n d a rds,  t  h e  N A V S U P  D a t  a  A d m i  n  i  s t  r  a. t  i  o n  Bran c h  h a s  been 
1. 1 1 e f  f  e ■:: t  i  v e  in  ass i  s t  i  n g  t he  i n f  o r m a t  i  o n  en g i  n e e r  i  n q 
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project.   Its  obvious  weakness  has  been  in  staffing.   Now 
that  the  goals  and  objectives  for  data  administration  have 
been  delineated,  NAVSUP  should  decide  what  it  is  going  to  do 
with  its  organization.   DA  cannot  evolve  effectively  as  it 
is  currently  located  and  manned.   If  a  true  IE  effort  is 
envisioned,  it  should  be  moved  up  the  NAVSUP  organisation  to 
either  the  SUP-OOX  or  SUP-04  level  to  give  it  the  full 
"top-down"  support  it  requires.   Otherwise  it  should  be 
moved  to  FMSO  where  the  knowledge  of  database  management  and 
design  resides  and  where  it  can  realize  its  objectives 
relating  to  integrated  data  design.   Then,  after  tangible 
benefits  become  evident,  consideration  can  be  given  to 
expanding  the  scope  of"  DA  and  migrating  it  to  headquarters 
for  higher  lev/el  administrative  purposes , 

The  UADPS-SP  redesign  project  is  not  a  true,  top-down 
information  engineering  project,   Nevertheless,  many  of  the 
issues  the  FMSO  team  is  addressing  are    top  management 
issues.   This  results  in  the  equivalent  of  a  "middle  out" 
approach  to  IE  which  makes  the  development  of  a  corporate 
data  dictionary  exceedingly  difficult.   The  NAVAL  SECURITY 
GROUP  for  example  required  six  months  just  to  standardize 
400  names  for  a  corporate  dictionary.   UADPS-SP  is  much  •r>or& 
involved.   With  the  current  time  restrictions  placed  on  the 
redesign  effort,  serious  consideration  should  be  given  to 
developing  a  dictionary  which  is  much  smaller  in  scope  and 
which  f  a.  c  i  1  1 1  a  t  e  s  the  trans  i  t  i  o  n  t  o  a  e  i  a  t  a  -  o  r  i  e  n  t  e  d 


UADPS-SP.   If  this  is  successful,  then  a  concept  known  as 
selective  retro-fitting  can  be  used  to  incorporate  new 
applications  as  they  arise  and  evolve  towards  a 
comprehensive,  integrated  corporate  dictionary. 

Today,  there  is  a  critical  need  to  integrate  information 
systems  within  NAVSUP.   Information  needs  throughout  the 
organisation  have  increased  tremendously.   The  capability  to 
have  an  integrated  system  exists,  if  NAVSUP  can  gain  control 
of  the  data.   SUADPS  Real-Time,  SPAR,  and  UICP 
RESYSTEMIZATION  began  at  different  times  and  ar&    in 
different  stages  of  development-   For  NAVSUP  to  properly 
integrate  those  systems  to  allow  worldwide  access  to  data  at 
ail  three  levels  of  the  logistic  chain,  it  will  have  to  free 
data  design  from  applications.   An  effective  data 
administration  organization  is  needed  to  ensure  the  data 
r  e  q  u  i  r  e  m  e  n  t  s  o  f  t  h  e  o  v  e  r  a.  1 1  c  o  r  p  or  a  t  i  o  n  a  r  e  satisfied. 
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